Procurement and intake were resolved by verifying Automation for Jira approval records and Workday JobProfil entitlements, recording approver and cost‑center corrections, and requesting missing PO numbers, delivery details and start dates before forwarding orders. Requests submitted via the wrong portal or form were cancelled/closed to avoid automation conflicts; support recreated New Mobile Device requests or supplied the correct portal link and confirmed threaded Automation responses. Orders were routed to Conbato (cpg‑requests@conbato.de), the mobilfunkbestellungen inbox, vendor storefronts (Google Store, Amazon) or distributor partners (GFDB) and placed as purchase orders; Conbato worklist cadence, vendor lead times and requested delivery dates were communicated to requesters. Manager approvals and Workday entitlement confirmations were required before orders were sent; Automation for Jira forwarded full order emails to Conbato and the mobilfunkbestellungen mailbox. Platform and MDM compatibility (for example iOS‑only MDM) and project‑level procurement restrictions were checked and enforced during intake. Delivery‑address ambiguities (c/o, bulk shipments, conflicting addresses or missing fields) were clarified; when direct delivery failed support offered re‑forwarding, pickup/collection or registrar‑first delivery for special accounts. Carriers and vendors (primarily DHL, UPS, GFDB and other couriers) were liaised with to obtain sendungsnummern/tracking, re‑route or re‑dispatch shipments, reconcile misdeliveries or returns‑to‑sender, and provide updated tracking and delivery receipts to contract owners and mobilfunkbestellungen. Shipping constraints such as the recipient name field limit (35 characters) were recorded. Vendor substitutions, refurbished/unit disputes, stock shortages and mis‑shipped models were logged and coordinated with requesters for returns, re‑shipments or refunds; physical defects were documented with photos and handled with vendor warranty returns or replacements. Provisioning and inventory mismatches (devices present without active mobile contracts, missing ownership/administrative assignment, absent DEP/ABM enrollment, or missing IMEI/EID/serial records) were escalated to provisioning and hardware operations for contract provisioning, ownership transfer, DEP/ABM enrollment or return‑to‑vendor; IMEI/EID/serial numbers and outcomes were logged in ticket notes. SIM/eSIM provisioning issues (including eSIM QR codes delivered by email) were addressed by re‑provisioning or re‑issuance and remote assistance; phone numbers or eSIM details were sometimes provided in advance to satisfy third‑party requirements (for example Twilio caller‑ID). Automation for Jira errors (misplaced reminders, missing acknowledgements, accidental auto‑closures or automation‑driven orders without model selection) were recorded and corrected with follow‑up communications or manual workarounds. Informational or eligibility inquiries about mobile policy were routed to the specialist mobile‑policy team. Replacement or consumable requests were declined when the employee’s Workday JobProfil did not entitle a replacement; works‑council exceptions were recorded with justification and explicit management confirmation before processing. Student device provisioning matters were routed to IT Operations – Student Support (techsupport@iu.org) when appropriate. When procurement backlogs caused orders to show no visible processing or delivery status, tickets were escalated and stakeholders were informed while internal follow‑ups to Conbato/procurement were logged. Legacy OTRS tickets for iPhone orders were confirmed to require assignment-to-recipient handling and were processed accordingly. Final outcomes (PO numbers, tracking IDs, serial numbers, reassignment, returns, repairs, insurance or disposal decisions, or explicit non‑reshipment/won't‑do outcomes) were logged in ticket notes and communicated to stakeholders.

Affected apps were republished and re-approved in the MDM Self Service catalog, which restored discoverability and allowed installations (Spotify was restored and installed successfully). Some stalled downloads completed only after devices were power-cycled — restarting tablets cleared hung Eventbrite installations and allowed them to finish. On devices restricted from the public App Store, users obtained approved Office/Microsoft 365 apps by installing them from the Selfservice catalog. In onboarding cases where users lacked the ability to install apps, IT obtained needed apps via the Selfservice app and advised requesting addition to the catalog when an app was not available. A new-device symptom was reported where an iPad Pro arrived with a personal Apple ID configured and the IU Group Self Service app missing; this was noted as an indicator that institutional provisioning/enrollment had not been applied and required IT intervention to restore MDM Self Service and app availability. The ticket corpus also showed Adobe Creative Cloud apps (Photoshop, Illustrator, InDesign) appearing in the same failure pattern on affected devices. An unrelated hardware issue (wrong Apple Pencil model delivered) was reported separately and handled as a hardware-replacement case.

Support resolved enrollment failures by reassigning MDM records when devices were found on the wrong management server and by performing local restores when over‑the‑air enrollment timed out or the Remote Management screen would not complete. Local restores were performed using iTunes (Windows) or Finder (macOS) in Recovery Mode or DFU via a Lightning connection; the Apple Devices App was used in some cases. Support documented that certain host/OS/tool combinations failed to enter recovery or stalled during erase, and successful restores were achieved after switching to a different Mac or bringing the device on site for a local restore. After MDM records were corrected and the device restarted, devices enrolled into jamf School and SSO sign‑in (Okta/Azure AD) completed using existing MFA tokens. When devices were determined to be faulty or unrecoverable (hardware/accessory failures, persistent non‑detection by host tools, or inability to enter recovery), IT shipped replacement devices, provided packaging/return labels and Apple ID sign‑out guidance for returned hardware, and procured replacements rather than continuing reassignment attempts. Additionally, in one case a replacement device that successfully enrolled into MDM could not complete eSIM provisioning because the eSIM activation QR/code was expired or invalid; that incident required coordination with the mobile operator or issuance of a new activation code for cellular service.

Problems were traced to managed/institutional Apple IDs (including managed Apple IDs tied to Apple Business Manager or another organization’s tenant) that restricted App Store downloads, device-to-device transfers, and Apple ID/iCloud sign‑in. Issues were resolved by replacing the managed/institutional account on the device with a non‑managed Apple ID (the user’s personal Apple ID or a newly created @icloud account), confirming the account was actively signed in in iOS Settings and the App Store, and reinstalling affected apps; after the account replacement, blocked updates, transfers, and new installations completed. When the device could not be disassociated from the institutional account (the “Remove from Account” option was not present), a new @icloud Apple ID was created and associated with the device; in several cases devices were reset and re‑enrolled per Apple Support guidance before creating the new account and reinstalling apps. Where devices appeared enrolled to the wrong management server or federated tenant, devices were removed from the incorrect server or support coordinated with the managing tenant, then re‑enrolled or wiped‑and‑re‑enrolled; once enrollment and Apple ID were corrected, App Store sign‑in and installs resumed. For devices where direct App Store installs remained restricted under an institutional account, required apps were delivered via the organization’s MDM-managed distribution/Self Service; Self Service installs that had hung were cleared after the Apple ID/enrollment correction and reinstall via App Store or MDM.

Support validated device model, serial and whether the device supported eSIM, collected MSISDN and contract‑holder records, and captured the exact activation error text before engaging carriers or activation vendors. When QR codes, activation links or provider access codes were expired, single‑use, or showed “already used” errors, providers reissued new credentials (or supplied a replacement physical SIM) and support delivered the new credentials to the user (including re‑sending QR codes or activation data by email when provisioning emails were inaccessible). Tickets were forwarded with approval/entitlement information to the service provider and internal mobile orders (Mobilfunkbestellungen) and flagged for entitlement/order‑authorization checks when provisioning failed due to order/assignment conflicts. Cases were escalated to specialist teams when provider‑side activation windows or scheduled activation dates prevented immediate activation; providers then rescheduled activations or reissued credentials as required. When providers reprovisioned an eSIM profile, users removed any old eSIM profile, installed the newly provisioned profile and restarted the device; reprovisioning restored full functionality, corrected incorrect MSISDNs and resolved receive‑only lines. Support removed an existing physical SIM from devices where the installed SIM conflicted with eSIM activation before installing the eSIM; if a device lacked eSIM hardware or could not accept transfers, support arranged a suitable replacement device or issued a physical SIM and updated registration/contract‑holder records and procurement/shipment as needed. Contract adjustments (for example increased data volume or enabling EU roaming) were applied by the provider when allowance or roaming settings explained no‑data or no‑roaming symptoms. Support validated APN and network selection when calling or data failed. When device sign‑in or app‑installation problems accompanied provisioning failures, support checked Apple ID/iCloud identity state and escalated persistent managed/organizational Apple ID issues to identity/cloud or Apple Business Account teams; third‑party app authentication and SSO issues were captured and escalated to application owners or SSO teams. Support also transmitted eSIM QR/activation data by email and offered remote assistance (for example via Teams) when required.

Support informed the user that Telekom line allowances and top-ups were managed via the carrier's self‑service portal (pass.telekom.de) and that the line holder had to view the current allowance and purchase additional data through that portal. No company-side quota change was applied by support; the user was guided to use Telekom self‑service to increase or top up the data.

Emergency and replacement mobile devices were procured and delivered through the established Conbato ordering flow driven by Jira Automation and the internal mobilfunkbestellungen mailbox, with entitlement checks against Workday JobProfil IDs and approvals recorded before order confirmation. For confirmed loss or theft approvals were bypassed and replacement orders triggered immediately and expedited when required; delivery estimates, tracking and order confirmations were communicated to the user or contract holder. Defective or unresponsive handsets (including cases that failed the soft reset sequence: volume up, volume down, long side button) were inspected and devices deemed beyond repair were replaced and shipped with tracking and return labels; returns were coordinated with the returns vendor (for example Smart Support GmbH). Emergency replacements were either signed into required corporate Microsoft/Windows accounts by an authorised colleague on site or by the assigned device owner; device‑specific iCloud accounts were created so ownership and 2FA did not depend on personal accounts. Where the employee’s number needed to be retained the eSIM was provisioned or transferred to the replacement handset; in one case a damaged physical SIM was replaced by a new eSIM. New eSIMs were provisioned as QR codes and delivered to users (QR shared via Teams and recorded in the ticket when used). IT noted that suspending or locking an eSIM stopped further network‑based location reporting and users enabled Find My Lost Mode after theft. When portal access was blocked because users could not approve Okta MFA, Okta MFA was temporarily disabled centrally so users could register MFA on a private device; after replacement MFA was re‑enabled centrally or the user reconfigured MFA in Okta. Application authenticators (for example Salesforce, Workday) were reset and new QR codes or replacement authentication codes were issued when scanning old QR codes returned “Error.” For theft incidents IT recorded and supplied device identifiers (IMEI, serial/model) to the user for police reports. On occasions when automation inadvertently created a replacement order, IT recorded the autogenerated order details (model, serial, assigned phone number), asked Conbato to send order confirmation to the contract holder, and coordinated returns or collection. Entitlements were verified against Workday JobProfil IDs before final approval.

Support resolved multiple incidents by arranging full hardware replacements when local troubleshooting and diagnostics did not restore functionality. In a time‑sensitive grading case a replacement iPad and Apple Pencil were supplied; the replacement was confirmed on 2025-02-10, serial numbers FJ6MXKN4KT (iPad) and HKFJYC24GWTJ (pen) were recorded on 2025-02-13, shipment occurred the same day, and the user confirmed receipt on 2025-02-20; a later keyboard request could not be fulfilled due to lack of stock. In a separate incident where an iPad reported “insufficient storage” blocking iOS updates and the Apple Pencil would neither charge nor pair, support ordered a replacement iPad and Apple Pencil under PO-008804 and used the device-return/order portal and supplier email notifications to manage the exchange. In another case of sporadic/intermittent iPad outages with no specific error messages, support collected a current delivery address and created purchase order PO-006797; the user was to receive shipment and tracking information at their IU email address once dispatched. No diagnostic error codes were available in these cases; replacements restored device functionality.

Blocked SIMs and eSIMs were either unlocked with the carrier-recorded PUK and a new PIN was set, or the handset was replaced and the phone number reassigned when the device was the root cause. In multiple incidents staff verified carrier-stored PIN/PUK values via carrier portals; in at least one case portal values matched supplied paperwork but the SIM remained blocked until the recorded PUK was used after forcing the PUK prompt. eSIM transfers were recorded as a trigger for locks and in some cases provided PUK values produced a generic "error" or failed to complete the unlock. Where entering the PUK returned the device to a PIN/PUK prompt loop or otherwise remained unrecoverable, technicians triaged the issue as a potential handset hardware fault (for example severe battery degradation) and provisioned a replacement device, reassigning the number. Technicians sometimes requested PUKs via the carrier portal or by contacting an external service provider/contractor and waited for an asynchronous response; carriers also occasionally required organisational account credentials before disclosing PUK data. Notable examples from the corpus included a Vodafone PUK value 89254378 being used to unlock a SIM and an iPhone SE (iOS 17.5.1, serial FFNGKFBVPLJQ, IMEI 357945441109258) with severe battery degradation being replaced and its number reassigned.

Restore and bypass attempts (Finder/iTunes restores, DFU, iOS 15.2 passcode-reset flows, recovery-mode) did not remove Activation Lock or clear an unknown Apple ID. Some cases had Apple’s account-recovery flow initiated and Apple’s messaging indicated a multi-day wait for password reset. Cases in this corpus were resolved only when one of three things occurred: the original Apple ID and password were provided, Apple Support removed Activation Lock after verification of ownership with original proof of purchase, or the unit was treated as end-of-life and securely disposed. Tickets also recorded separate cellular/SIM problems: reporters later obtained account credentials but the physical SIM or eSIM showed no network (SIM PIN accepted but no service), suggesting carrier-side deactivation or required carrier reactivation that was independent of the Apple ID/Activation Lock state. No in-house restore or DFU sequence succeeded in removing Activation Lock without owner credentials or Apple Support intervention. Organizational handling routinely instructed users to follow Apple’s account-recovery process and wait the indicated recovery period; devices still inaccessible after that period were returned to the organization for further handling.

Support inspected the device Phone app and OS call settings and confirmed there were no network outages. They checked call-forwarding and blocked-caller lists, notification permissions, and the Phone app’s allowed/notification state; in cases where blocked or forwarded calls were corrected and notifications were enabled, incoming calls resumed. For iOS devices (including an iPhone SE report) support also checked blocked contacts, Focus/Do Not Disturb and the Silence Unknown Callers setting, and reviewed caller-ID formatting for country codes. When a problem appeared limited to a single caller, support recommended recreating the contact entry and restarting the device to address potential contact/caller-ID corruption; these iOS-specific troubleshooting steps were documented though outcome in the referenced case was unconfirmed.

Technicians requested and recorded device serial numbers, verified the hardware was absent or previously deleted from Jamf (and not enrolled), and confirmed the device did not appear in Apple device inventory sources (Apple Business Manager / "Apple Geräte" app). Because the devices were not enrolled in Jamf, no remote wipe or remote reset could be executed from the MDM. Per request, devices were removed from Apple Business Manager to complete deprovisioning despite the lack of Jamf enrollment. When users reported forgotten passcodes and the device was not manageable remotely, support provided user-facing recovery/reset guidance and asked for correct serial numbers when discrepancies were identified.

The device was connected to a computer running iTunes and a full device reset/restore was performed via iTunes. After the iTunes restore and completing the on‑device setup, the iPhone returned to normal operation.

When target handsets supported eSIM, support exported the eSIM profile and delivered it electronically (email) to the requester and confirmed receipt. For routine device or on‑call equipment requests, support communicated shipment and tracking details to the requester by email. When external vendors or service providers were required, support followed up with the vendor to confirm whether the eSIM/SIM, device, or accessories would be mailed and, in several cases, the vendor completed provisioning or mailed the SIM/eSIM directly to the user. If the target handset lacked eSIM support, a physical handset that supported the required SIM type was procured and shipped. Missing physical SIMs, eSIM delivery failures, or absent accessories (case, screen protector) were ordered from the service provider and replacement items were shipped. Requests that included carrier data plans or specific device models (for example, an iPhone 15 with a 10GB/month SIM) were forwarded to the external provider for provisioning and marked done once the provider completed fulfillment. Support confirmed delivery addresses and any recipient pickup requirements before ordering, and confirmed receipt of emailed or mailed eSIM/SIM and any shipped accessories before closing the ticket.

A live troubleshooting session over Teams was attempted to confirm symptoms and rule out quick configuration issues. The device was determined to be unreliable for cellular and Wi‑Fi connectivity and a replacement iPhone was ordered and issued; the ticket was closed after the replacement was arranged.

The device (iPhone 11 running iOS 18.5) was erased using 'Erase All Content and Settings' (factory reset). After the reset the abnormal System Data usage was cleared and the device storage returned to expected levels. The ticket was closed after confirming storage behavior normalized post‑reset.